…pe=...`

In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.

So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.

Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.

I found these with a hacky shell script.

There are a few common abbreviations like `use rustc_ast as ast` and
`use rust_hir as hir` for names that are used a lot. But there are also
some cases where a crate is renamed just once in the whole codebase, and
that ends up making things harder to read rather than easier. This
commit removes them.

This is a case where `rustc_parse_format` is renamed as `parse` but a
couple of places don't take advantage.

zkvm is single-threaded, similar to emscripten and wasm.

Use a proof tree visitor to refine the `Obligation` for error reporting in new solver

With the magic of `ProofTreeVisitor`, we can close the gap that we have on `ObligationCause`s being not as descriptive in the new trait solver.

r? lcnr

Needs some work and obviously documentation.

Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`

In the stabilization [attempt](rust-lang#120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](rust-lang#120832 (comment)) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward.

So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature.

Another point was [also raised](rust-lang#120832 (comment)), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.

Tracking issue: rust-lang#97889

…ckh726

Trim crate graph

This PR removes some unnecessary `Cargo.toml` entries, and makes some other small related cleanups that I found while looking at this stuff.

r? ``@pnkfelix``

…ulacrum

release notes 1.78: add link to interior-mut breaking change

Cc rust-lang#123248 (comment)

r? ``@Mark-Simulacrum``

…, r=jieyouxu

Migrate `run-make/doctests-keep-binaries` to new rmake.rs format

r? ``@jieyouxu``

…plit-at-checked, r=jhpratt

Stabilize `split_at_checked`

Closes rust-lang#119128

For the const version of `slice::split_at_mut_checked`, I'm reusing the `const_slice_split_at_mut` feature flag (rust-lang#101804). I don't if it okay to reuse tracking issues or if it preferred to create new ones...

zkvm: fix run_tests

`zkvm` is single-threaded, similar to `emscripten` and `wasm`. The `cfg` for `zkvm` seems to have been dropped. This PR adds the `cfg` again.

… r=compiler-errors

Make `Bounds.clauses` private

Construct it through `Bounds::default()`, then consume the clauses via the method `Bounds::clauses()`.

This helps with effects desugaring where `clauses()` is not only the clauses within the `clauses` field.